I wonder how useful is it, to save this to files, instead of printing to stdout? Can't we just parse the stdout wherever we need to use this? 🤔

1. I based this off of the decision we made in the past regarding scarb prove: Add scarb prove #1900 (comment)

   Although I'm not sure that's super problematic since we have control over the logic of both extensions, I suppose if extracting N from Saving output to [..]N is unstable, then extracting multiline outputs could be considered even less stable 🤔
   That's why we use SCARB_EXECUTION_ID, and it seemed reasonable to me not to rethink this here

2. Another thing that concerned me - verbosity.

   • If we pass verbosity from doc to execute, and that verbosity is --quiet, the output is lost
   • If we force a normal verbosity for execute, we'd have to capture execute stdout, and then somehow figure out based on doc verbosity what to print and not to print. Since we'd have only raw text at our disposal, there would be no way to filter out messages based on their intended level and doc verbosity
     Maybe there's some elegant solution to this, but I just didn't think it's worth going there since the files should just work 😄

I see your point, but I don't really think these two are comparable.

For starters, I don't think that using HintProcessor to capture print is reliably what we want. It seems it can be bypassed (see running with bootloader), but also it runs on the assumption that println! it's the only possible way to access stdout (which I am not sure is true).

It shouldn't require any unpredictable parsing, as we can expect the program output to be the last message when run with --program-output flag. We can use json output format in ui, to output it as easily parsable json. We can also do what we do in scarb metadata, that is, run the command with --quite, but set the output to always be printed regardless of verbosity (imho makes sense, if you are explicitly for it to be printed).